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Abstract/Line Hem Overview 



1,0 Abstract/Line Item Overview 



This document describes the infrastructure and interfaces provided for Linux and ADC cluster envi- 
ronments to provide a secured application execution environment. The infrastructure and i 
are designed to provide these capabilities: 



> interfaces 
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Provide a generic interface for authentication and authorization, to make it easiejr for 
cluster components to implement security, and to permit cluster components to us< com- 
mon code for authentication and authorization regardless of the specific security mecha- 
nism used to provide security within the cluster. j 

Provide the capability for system administrators to install and configure an AIX br Linux 
cluster to use an authentication method that the customer can select. The initial bf! bring 
will support Kerberos 5 based authentication, Unix operating system based autljen ica^ 
tion, and permit the addition of other authentication mechanisms in the future. Utilities 
are provided for setting the authentication methods, providing the necessary information 
about these methods, and enable these methods within the cluster. j 

Provide the ability to easily port the infrastructure to the SP computing environrherlts. 
This permits existing SP subsystems to migrate towards a common security interface in 
the future, and can facilitate the porting of existing SP components to Linux an^ AIX 
clusters. Common source code can be achieved for components whether the code is 
intended for the SP, AIX clusters, or Linux clusters. 

Provide equivalent security functionality and interfaces for 32 -bit computing environ- 
ments and 64-bit computing environments. 
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2.1 Line It em TVacking Information 

This system design is associated with Pipeline Line Item AU7 and CMVC line item tracking feature 
69772. 



J . "aznAPr is a proposal offered by DASCOM Incorporated, 1 999. 
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Change History 



2,2 Implementation Stag in g Information 

This document does not discuss the delivery schedules or staging of the function proposed! by 
design. Those interested in this information are directed to consult the release plan for this! 
This information is available from the Security manager and the Security team leader. 
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3.0 Requirements 
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3.1 Requirement As Provided 

The following is a list of requirements which can apply to a security infrastructure offering fj>r 
and AIX clusters. Those requirements accepted by this specific design are listed in following sec- 
tions. Requirements not addressed or postponed will be explained as well. j 

1- Provide an infrastructure and a corresponding set of interfaces for application use to protid 
secured operating environment in Linux and AIX clusters. Provide facilities for Linux arid j 
cluster components to authenticate and authorize other parties. Provide functions that pejmi 
Linux and AIX cluster components to transmit information securely, in a fashion that permits 
component to verify who transmitted the data and that protects the privacy of the data. Pfov 
storage facilities for the data objects necessary to authenticate and authorize other partiei 

2. Provide an interface that promotes the development of common security code within Lix^ux 
AIX cluster components. Remove the need for Linux and AIX cluster components to 
the specifics of the security mechanisms in use within the cluster, and reduce the need fojr 
component to implement common functions such as error handling. 

3. Provide a security infrastructure that does not require a specific security mechanism to b£ i 
the customer's environment. Allow the customer the flexibility to use the security mechaijri! 
the customer prefers. Do not force the customer to make use of a specific mechanism. Aji 
pie of this requirement would be to not force a customer to install and configure Rerbercjs5 
another security mechanism is preferred by the customer. 

4. Provide an authentication scheme that exploits existing operating system assurances thatj th0 user 
is authentic. These assurances are weaker than assurances provided by a "trusted" third ii 
security mechanism, but can be used to provide minimal (but certainly not foolproof) secur 
assurance when it is not possible for the customer to install or use a "trusted" third party security 
mechanism such as Kerberos version 5. An example of such an authentication mechanism i 
Unix domain socket (UDS) authentication scheme that is used extensively within PSSP an 
RSCT component that are being provided in the initial Linux and AIX cluster. Another exanjple is 
the host-based trust employed by remote commands such as rsh and rep. j 

5. Provide a security infrastructure capable of supporting security mechanisms that may be|coi 
available in the Linux and ADC cluster environment in the future. Providing this support [should 
only require a configuration alteration of the security infrastructure, and not an alteratioxj of 
Linux or AIX cluster component binaries or source code. 

6. Provide an infrastructure and interface compatible to previously provided security 
on other supported AIX platforms, such as PSSP's S3 security services subsystem, to asiist 
porting existing PSSP components to Linux and AIX clusters. 

7. Provide an infrastructure and interface that can support nodes existing within Linux clusjti 
other AIX clusters or SP configuration at the same time. The infrastructure and interfacejs 
need to coexist and possibly cooperate with existing security infrastructures previously 
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10. 



for these platforms, such as PSSP's S3 security services subsystem. Such a solution woujd 
tate cooperation and workload sharing between Linux clusters and existing AIX clusters jor 
systems. : 
Provide a secured environment for Linux and AIX cluster software installation, to prevent the 
installation of malevolent software or utilities that can jeopardize system security and function 
Provide support of security mechanisms that are consistent with the long-term direction <j>f I 
and AIX development within IBM. This direction currently dictates that Kerberos versioh 5 
used as the security mechanism for AIX and Linux offerings initially, with support for certificates 
based authorization following in the near future. 

Allow for an AIX or Linux cluster to be used in an insecure mode. Allow a customer to 
a cluster where no security software such as Kerberos version 5 is required to operate the sybtem 
Do not require the installation of security software if a customer chooses not to secure th^ cluster 
and do not impose extra overhead on the cluster operation in these modes. 
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Linux cluster component development places additional generalized requirements upon a software 
development project: 

1. Do not require the use of a globally accessible, distributed data repository. Unlike the SPj's 
tern Data Repository, Linux and ADC clusters do not provide a default distributed repository 
design that requires a distributed repository must therefore furnish one. 

2. Do not require a single point of control. Allow system administration tasks to be perfornjed 
any node within the cluster. Do not serialize specific functions to a node based on the node': 
ter identity. Unlike the SP's Control Workstation, Linux and AIX clusters cannot be assuknejd 
provide a centralized point of control for administration and coordination purposes. 



The following are a set of general requirements imposed upon any software project developed by 
IBM Unix Development Lab. ; 



ice 



Provide a reliable security infrastructure and interface. Reliability is defined as the assur^n 
the infrastructure and interfaces will always function properly when used correctly, and Wh£n 
necessary resources are available. In other words, the product is to be "bug free". 
Provide interfaces that support 32-bit and 64-bit execution environments, without restricting the 
function offered to clients in either environment. 

Provide a security infrastructure and interface that can easily be ported from the Linux c| 
ADC clusters and SP environments. This is consistent with the laboratory's long term strite^y 
merging Linux cluster and AIX cluster offerings into a common spectrum of offerings fdr 
Unix based platforms. 

Provide a solution that is scalable to Linux and AIX clusters with numerous nodes. Use 
security infrastructure and interfaces in a large Linux or AIX cluster should not impose 
operational overhead than the use of the same infrastructure and interfaces in a smaller 
AIX cluster. 
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5. Provide a solution that achieves the correct balance between security of the system and p^rf 
mance impacts on users of the security infirastructure. These tend to be contrary goals. 

6. Provide sufficient serviceability support within the product. Provide sufficient ability to 
shoot the security infrastructure during execution, and to diagnose potential problems in the 
structure. 

7. Provide interfaces that are consistent in look-and-feel with industry standard interfaces 
existing internal conventions and industry standards for such interfaces wherever possiblje 
sider the usability of such interfaces in the design and implementation. 
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3.2 Requirements As Interpreted . 

A security infrastructure must be provided for Linux and AIX cluster computing environments 
infrastructure must provide function to cluster services, client applications, and client users tip a 
ticate other parties (ensure that the other party is who the other party claims to be) and to enjmre 
other parties are authorized to request or perform specific functions (ensure that the other party 1 
sufficient privilege to carry out the request it is making). The security infrastructure roust prjjyi ie 
clear assurance that the identities of cluster services, client applications, and client users carj|no : 
forged by malevolent parties, which would permit a breach of system security. 
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Several technologies exists to provide authentication today in a Linux environment, just as in 
cluster environment Linux customers are free to choose the software they deem best - Kerb* 
DCE, Verisign for their purpose. Unlike ADC cluster and SP environments where IBM provides 
total computing solution, IBM provides only portions of the Linux cluster solution. IBM Lujiu> 
ter software can be installed on a wide variety of Linux platforms. This poses a challenge toj IB 
Linux cluster software: the software must be able to operate correctly in a wide variety of cdnfjgura 
tions. Security is one area where a variety of configurations may exist, and given that IBM can 
control the variety of configurations, IBM Linux and AIX cluster software needs to be flexible 
enough to operate in a variety of security environments. 

This flexibility can be achieved in a number of ways. One method is to make the cluster sof|w 
aware of all possible security methods that can be employed. The software would detect whjich 
method was currently in use, and employ the correct source code to utilize those methods. T 1 *-* 
nately, this approach requires each cluster component to invent their own means for dealing 
tiple security methods, leading (at best) to redundant code or (at worst) to feulty code employ 
some cluster components. This approach also requires a reworking of all cluster software coita 
whenever new security mechanisms are made available for the cluster platform to support the 
mechanism, requiring new tests of the same software components. 

To avoid these problems, an abstraction layer is inserted between the cluster software compjon^nts 
and the underlying security mechanisms used in the Linux or AIX cluster. This abstraction 
responsible for determining what security methods are available in the cluster, and employs 
appropriate code to perform the necessary security functions on behalf of the cluster compdne it 
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Common error checking and handling functions can also be integrated into this abstraction l^yejr, 
helping to achieve further code commonality. The cluster component remains unaware of the! ui der- 
iving security methods. Should a new security mechanism be made available for the cluster, <[>nly this 
abstraction layer needs to be modified to support the new method, and only the abstraction la|ye r 
would need to be tested to verify that the support is correctly implemented, cluster software corjipo- 
nents, abstracted from the underlying mechanism, require no modifications or new testing. 

Injecting this new abstraction layer helps the cluster software components to implement common 
code for performing security functions. However, achieving common source code is insufficient. The 
security infrastructure must provide the capability for Linux and AIX cluster components to (employ 
the same executable program in the cluster, instead of employing a different executable for each 
sible security configuration. In addition to providing a common interface for cluster services 
ent applications to use, the security infrastructure must provide a common service for these d 
and applications to use. The service or application should execute the same binary every timis ill the 
same cluster platform. The security infrastructure must be capable of determining what underlying 
libraries or modules would be needed to interface with the configured security mechanisms, pc load 
those modules as the service or application executes. This function is abstracted from the clu$tei com- 
ponents, who are not aware that it is being done on their behalf by the security infrastructure! 
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Another goal of achieving code commonality is to develop common source code for all platf^)] 
where the software component is offered. Using common source code for all platforms reduces 
development and servicing complexity of the software. Injecting an abstraction layer to handle 
anism differences helps to achieve code commonality on one specific platform only. Componei 
provided for multiple platforms AIX clusters, SP systems, and Linux clusters — do not detfive 
full benefit of common code from such an abstraction layer, unless that abstraction layer is ajvai 
on all these platforms. Without it, the software components still need to provide separate code 
for different platforms. Although this design assumes that the initial implementation will be ^>ro 
for Linux clusters, the infrastructure and interfaces provided by this design are designed to 
ported to AIX and other Unix based platforms. Industry standard coding practices and in 
used wherever possible, and platform specific code is isolated to specific code paths to allowjfor 
future porting efforts. 
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The security infrastructure must be capable of supporting multiple security mechanisms. 
IBM does not have control over the entire Linux cluster software solution, the security 
needs to be flexible enough to support a number of possible security mechanisms. Initial 
the Linux cluster security infrastructure will restrict what security mechanisms can be emplcjyejd 
the initial offering, but the security infrastructure will be designed so that support of additional 
rity mechanisms can be provided in later releases through provision of mechanism-specific 
instead of requiring a reworking of the security infrastructure itself. This reduces the retestirig 
of the security infrastructure to a verification of the new mechanism-specific modules, instead 
requiring a complete new test of the entire security infrastructure source code. ] 
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In addition to authentication, cluster components require the capability of authorizing other paries. 
Even if a party has been authenticated by a cluster component, it may choose to restrict certain 
resources or functions from all but a specific set of requestors. For this reason, cluster comp4ne|nt 
require function to determine which parties are authorized and which are not. 



As with authentication, there are several existing methods in Linux clusters for providing this aiithori- 
zation function. Once again, IBM cannot control what specific mechanism is used to provide this 
capability. The cluster components either need to know about all possible mechanisms that dan T 
used, or this information also needs to be abstracted from the cluster components just as the 
cation mechanisms have been abstracted. The wiser choice is to abstract the mechanism and I 
vide a common interface for all cluster components to use for authorization purposes. These 
interfaces allow cluster components to create, modify, and remove authorization privileges for .j] 
cific parties, and to verify whether specific parties are granted sufficient privileges within thijs ] 
for the Linux cluster component to allow that party to proceed. 



The security infrastructure provides interfaces for 32-bit and 64-bit execution environments 
function is available to clients in both environments. Application programming interfabes 
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low conventions specified by POSIX and existing security interfaces in the industry; should 
conventions differ, the interfaces provided by this design choose to imitate existing security i atelrfaces 
to provide a consistent look-and-feel to them. Interfaces are also provided to security system) adminis- 
trators to configure the security infrastructure. 

Performance remains a key requirement in cluster environments. Clusters are created to improve 
performance of large workloads by segmenting and sharing the workload amongst many price 
Therefore, any new infrastructure introduced to a cluster environment must avoid degradin; 
all performance of the cluster or a single node in that cluster any more than absolutely nece: 
Function should be performed in the shortest code path possible, with the least amount of b 
and waiting necessary. Unfortunately, the requirement to secure the cluster operation is com 
these goals of performance. Providing a secured environment requires that applications incr 
some degree of paranoia. Applications must verify identities and permissions of their clien 
to the code path length. Such verifications may require blocking or waiting for a "trusted*" 
confirmation, further adding to the operational overhead. 

tradel-oft must 



To resolve the inherent conflict between the performance and security requirements, a 
be made. Some degree of operational overhead is imposed upon users of the security ' 
The security infrastructure and its interfaces are designed to m in imi ze the amount of 
sary to provide a secured operational environment Users of the infrastructure and interface!* 
accept this overhead as a consequence of using a secured execution environment. Should 
overhead be deemed unacceptable, the application will need to make its own trade-or 1 
rity and performance, and decide whether the performance needs outweigh the needs of sedurijty 
their own product 
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The security infrastructure and interfaces provided by this design are scalable to clusters cc|nt4ining 
numerous nodes. Applications using the infrastructure should not incur more operational oVe 
from the infrastructure itself if the application executes on a 128 node Linux or AIX clustej- thlan it 
would executing on a 16 node cluster. The security infrastructure avoids use of global data Requiring 
exclusive access from a single node, and any cases where such access is required is restricted 
figuration activities performed by security administrators only. 
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This design introduces a software layer on Linux and AIX clusters which is critical to the flrojper exe 
cution of cluster components. Because of this, the security infrastructure provides reliability 
ance and serviceability features above and beyond those provided by typical Linux software 
Compliance to the IBM Unix Development Lab's internal policies of thread safety and reliability 
expected. Cluster components must be assured through sufficient code examination and te^tin 
the security infrastructure and related interfaces are reliable. The infrastructure also provides 
ability features such as execution traces and diagnostic utilities to assist in the run-time an^lysjis 
troubleshooting of the infrastructure. When properly installed and invoked, the security 
will provide a minimum level of execution tracing that can be used to verify the 
nect operation, plus additional levels that can be activated at the system administrator's rei 
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This additional layer of software is included as part of the core set of utilities required by the 
and AIX cluster software. The security infrastructure is installed even in cases where the chstfcmer 
may wish to operate an insecure cluster. This is required because all cluster trusted serviced 
coded to invoke the security infrastructure routines in all cases, whether or not the cluster is 
ured fo be secure. Instead of forcing the cluster trusted services to check whether the clustejr is 
ing in a secured mode, the security infrastructure makes this determination. This provides 
means for determining the security status of the cluster, permits the cluster trusted services] to 
same source code path for both secured and unsecured clusters, and permits the cluster truste< 
vices to handle a shift from unsecured to secured operation more efficiently. Operating anj} 
AIX cluster in an insecure mode is not likely, but should such a cluster be configured, a minir lal 
amount of overhead is imposed on the cluster trusted services. The security infrastructure wil 
that the cluster is executing in an unsecured mode, and label all users as unauthenticated, 
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4.0 System Design Overview 



The goal of this system design is to provide a secured execution environment for Linux and / JX 
ter software components that reduces the complexity of interacting with the security infrastnjictire 
and promotes die development of common code for these components. 
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Specific objectives of this design are: 

. Provide trusted services, client applications, and system users with an identity tMt 
used to verify them and their access permissions. These identities are provided throujjh 
use of existing industry security mechanisms. Kerberos version 5 is chosen as the se 
mechanism for the initial Linux and AIX cluster release. Support the addition of klt<trnate 
security mechanisms for this purpose in the future. 

• Provide a generic, security mechanism independent authentication and audiorizatjior 
face to trusted services and application clients. This interface abstracts the underf 
security mechanism, promoting the use of common code in the cluster components 
applications. A new application programming library is added to the cluster soft^arle 
offering to achieve this goal. 

Provide a generic, security mechanism independent interface to trusted services 2nd 
cation clients to transmit information in a secured manner. This interface must bo capable 
of protecting sensitive data so that only authentic parties can interpret the data, apd 
capable of signing the data to prove the authenticity of the transmitter. The same 
tion programming library proposed in the previous bullet also addresses this objective, 
. Provide methods for installing the security infrastructure and the generic iabstract ior i 
interface. CtSec supports the use of the installation mechanisms employed by IBM 
cluster software, as well as the installp method used in AIX clusters.. 

• Provide methods for configuring the security infrastnicture, A combination of mf mu 
cedures and semi-manual convenience utilities are provided to perform this func ion, 

• Provide a complete set of administration commands to control the operation of the 
rity infrastructure. 



These new functions are provided in a manner that does not prevent existing cluster compoi ents and 
applications from making use of existing security services and interfaces, such as using KerberosS 
directly. 



This design makes the simplifying assumption that all nodes within a cluster make use 
underlying security mechanisms. If any node does not make use of the same security 
example, the node chooses to use Certificates based authorization only, while other nodes 
ter support both Certificates and Kerberos 5), the node is considered not to be a member 
ter. In those cases, the security infrastructure will not guarantee that parties from that node 
authenticated or authorized. Another way of stating this is that a cluster is (partially) define^ 
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of nodes using a common set of security mechanisms; any node not meeting that criterion is 
sidered a member of the cluster. 
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4.1 Background - Current Linux Cluster Security E nvironments 

This design specifies an infrastructure and related set of interfaces to provide a secured 
environment for Linux cluster software. A description of the current Linux cluster security efivi 
ment is necessary, to understand how the new offering fits in with the existing methodology. 
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Traditionally, Unix applications that have required a secured execution environment have necdejd 
select one or more security mechanisms to provide security identities to various parties in the 
trusted services, client applications, and system users. Kerheros version 4, Kerbcros version 
DCE are some of the mechanisms that have been traditionally employed in this capacity. Thepe 
anisms provided unique identities to all parties, and acted as a broker on behalf of these parties ^uring 
the setup of a secured communication path. The parties involved in the transaction would trust 
security mechanism to verify the identity of the other participant, ensuring that the other participant is jj 
valid and not trying to forge another identity to gain access to restricted aspects of the systerji 

Using a specific security mechanism required the application to use mechanism specific interfaces for j 
some security functions. While industry convention insured that a security mechanistn provilei 
would provide a GSSAPI library for authentication functions, applications had to resort to 
specific interfaces to obtain their own security identity: to "log on" to the system and obtain thejir 
security credentials. Applications seeking to support a variety of differing security mechanisms 
forced to provide mechanism specific code for obtaining their security identity, which differed 
depending on the security mechanism that was in use on the system. Either the application 
have to provide different binaries for each security mechanism it supported, or it would havej 
porate logic within it to detect which security mechanism was in use and to load a module spec 
that mechanism. 



ron- 



Ito 



would 



curity 



The following diagram depicts a model in which an application attempts to support different se 
mechanisms within the same binary. Such approaches are necessary for service daemons that listen 
upon a network port, where only one executable program must be configured to accept request; 
that port To support multiple security mechanisms, the application partitions the security inj 
code from the rest of the application. The application invents new routines to handle the secui 
function, which will eventually map to corresponding routines in the underlying security mi 
nism's library. At execution time, the application determines which mechanism specific moi 
must load, corresponding to the security mechanism that as been installed and configured o4 th,at sys- 
tem. 
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FIGURE 1 



Note that in this example, the application must provide mult: 



Example structure of an application that supports rr ultiple security i ejebanisms in the same executable prograjn, acpicting 
the application's point of view. 



3(le binaries, must determine wpat under 



lying security mechanism is currently in use, and load the cc itect binary for the collect security 



mechanism. The same procedure would have to 



would attempt to support multiple security mec lanisms 
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A facility has been made available on Linux 
"logging in" to the security mechanism and ol 
tion Modules — remove the need for Linux appl 
pose is to abstract the specifics of the underlying 
providing a common interface that can be used 
system. PAM handles the problem of determining 
general "log in" call to the security mechanism 
dentials are obtained via the PAM interface, the 
GSSAPI interface to authenticate other parties 
provide PAM support in that platform as Well. 



platforms to hel] 
ibtaining its crec 
ipations to wrMe 
security rrie 
sgardless 
which 
specific versiH>ii 

tpplicationi 
Suture versioiii!! 



While the PAM mechanism abstracts the flog in 
the application must still know what underlying 
to know what library must be used to perform 
PAM reduces the amount of mechanism s pecific 
cation still needs to include logic for detejrminin 
for selecting the correct library to use. j 



'and 

security mec 
ajthenticatioin 
code that an 
; what undei ; 



The following diagram depicts an application usfng 
function. While a certain amount of mechanism 
not truly abstracted from the underlying security 
PAM in achieving a secured execution 
underlying security mechanism and usin^ 
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FIGURE 2 Example structure of an application that s upports r tultiple security » < nanisms, using the Pluggable Authenticat on 



Module (PAM) mechanism for obtaining 



security i i entity and credt n lis. 



4.2 CtSec Mechanism Abstractic 



CtSec is the security infrastructure provided 
structure implements a programming library 
lowing general categories of security fuiction 

Retrieving the application 's s ecurity] identity and 
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Authentication of the request* 
. Authorization of the requestor 

From the application point of view, no 
The application simply binds to the CtSe<; 
application as to what security mechanii 
sions are left to the CtSec library itself, 



FIGURE 3 
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ring security mechanism is r< squired. 
:isions need to be made within he 
erfaces to load and call. These ieci- 
bly in the application's point off view. 



Example structure of an application using 
point of view. 



ultiple security mechanisms, from the 



CtSec provides an interface independent 
obtain their security identity and 
tion environment, and verify the 
CtSec maps these mechanism independent 
interfaces to perform the function on behilf of tl|e 
depicted in the following graphic 



ity mechanism for applications 
parties to establish a secured tnmsac- 
a secured transaction environiient 
e underlying mechalnism specific 
IjThe internal components of (JtSec are ! 
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Application 



CtSec Infrastructure 




Mechanism Abetrac tl on w 



Mechanism Ab rtractior 



Common Authentication Ccfriponent 
(CAUTH) 



Configuration 



Encryption 
Component 



Mecli anism 
Modi le Interface 




Security Mechanism 1 
Pluggable Module (MPM 



MPMI Entry Points 


Security 


Security 


Mech 1 


Mechl 


Library 


GSSAPI 



Securi y Meet an Ism 2 
Plugge ble Mo lule (MPM 



Secu! ity 

Mech2 

Libraiy 




Security Mechanisms 

1 



^se 



FIGURE 4 Internal components of the CtSec infrastn cture. 



Trusted services and client applications iivoke 
(abbreviated in this document as MALI) to perf 
applications request and translates it to t ae proi er 
ports three primary categories of security function 



Obtaining the application's 
provided by the Common 
CAUTH). 
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Authenticating other parties 
This function is also provided 

Verifying the authorization of 
Authorization Layer (abbreviated 



part 



tes. 



a$d processing secur^pata between authenticated 
ntication Layer (CAUTH), 

fWnbtion is provided by the Con^mc^n 
(l>cument). 



by the 

other 
as 



The MALI, CAUTH, and CAUZ layers 
ated MAL in this document). CtSec provides thi ; 
ble Modules (abbreviated as MPMs in thijs docmpent) 
security mechanisms supported by CtSec 
security mechanism specific identities an<S credentials 
security mechanism provides, such as GS 



wot 



cpllectivply form the 
layer, as 
tailored 
Mlechanism 
for the 
braries if thi 



The 
icre< 
SAPI1 



4.2.1 CtSec Common Authentication L iver fC AUTH1 Co in 1 lOOent 



echanisms 
>f othej* parties, anc 

This 
configured on the 
mi schanisms, 



CAUTH is responsible for obtaining a security h lentity, secujip 
tion by using the currently configured security n 
ing functions required for authentication 
these parties in a secured execution environment . 
which security mechanisms are currently 
ule (MPM) to interface with those configjired 
credentials for the application. 



part 



The CAUTH component is provided as 
within the laboratory. Fox CAUTH to funbtion 
with the configured underlying mechanis n 
about the MPM's location and any special 



4.2.1.1 CAUTH Configuration Information 

CtSec 's CAUTH component must be informed c|f the 
the location of the mechanism pluggable 
nisms. Without this information, CAUTt 
form authentication functions. 



CAUTH configuration information is rec >rded t > a private 
reside locally on all nodes in the cluster. The name and 
by the component design. 



The CAUTH configuration can be implemented 
each security mechanism that is installed 
entry. 



Mechanism Mnemonic 
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Pljuj ;able Modules permit CtSec 
a 3 plication, using the interfaces 
nechanism provides such sup;joi|t 
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instructions on how 
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security 
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credentials, and keys for an ap jlica- 
UTH is also responsible for >eiform- 
r processing data foruse between 
compty^nt is requires an understandiig of 

, loading the correct pluggable mod- 
obtaining the security identify 4nd 



it 



ro:e. 
ami 



as a simple 
on the node. The 



10 



, and consists of code developed 
jgable module (MP1&) associate 
od, and CAUTH must be info|rm|ed 
he module must be loaded. 



nod 



mechanisms installed on the 
a^Qciated with these security m^ch|a- 
appropriate module- to load 



ldcktion. This location is expected ttj> 
direcoiy location of this file will be provided 



ASCII file, consisting of one rec ord 
fqljc wing information is required 



A symboli ; name for th e t ecurity mechanism. The mnemonic is 
a string sui :h as "krb5"j ttrM", "dee", "cert", etc. 
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Invocation Options 
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(MP M) pro 



Argi iments i ised during th e 
required. 



CtSec configuration procedures permit th 
directly modifying the configuration file 
aged. The purpose of the CtSec configurati 
provided for the cluster trusted services 



5 syste^i 
Direct 
on pr(»ceduri 
are 



that 



i to v 
iOAUZ 
ies o 



CAUZ provides applications with utilities 
function within the application. CtSec's 
not depend upon the authorization capability 
is taken because not all security mechanisms cuin 
their own authorization capabilities. To e: lsure tl 
ity even when the underlying mechanisms do no ': 



dita 
tliat 



or 
do 



4.2.2 CtSec Common Authorization La|ver fC K\m ConnjoM ent 

vcr fy a party's nithorization to access protected 
\ c amponent pi ovides authorization capabilities 

the underly iijg security mechanisms. This direction 
ently availa ble for AIX and Linux Clusters 
at CtSec is iitfvays capable of providing this 
support, Ctppc CAUZ provides its own. 



In some security mechanisms, each instance of a 
identity. For example, the trusted service "zathr^s 
different security identity than the instant ;e of 
instances comprise the same service. Thi i poses 
for these trusted services. Any 
an access control list (ACL), would have 
The more trusted services, the longer the 
the ACL must be. Not only does this pos£ 
problem for trusted services attempting 



Some security mechanisms offer security 
groups work in the same fashion as user 
be assigned to a group membership, and 
checks. Instead of needing to know the 
on group membership. Any identities thajt 
that user was explicitly denied access in 
number of groups would not be required 
bership within already established group£ 
rity identities, ACLs can instead be 
relation to the size of the cluster, the AC^s 
problem. 



Unfortunately, not all security mechanisths prov ide security 
coming, CtSec implements its own security identity grouping 
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to local operating system identities, and 
ating system groups. On each node within 
is mapped to an application's security 
operating system groups, using standard 
vider checks the authorization of a servicje 
associated with the requestor's network 
with that identity from the operating system, 
for matches using the following order: 



Associating 



Searches for matches to the r^questo 
Searches for matches to the riquesto 
Searches for matches to the n questo 



The mapping can be provided either by 
provided by CtSec or the Cluster softwar^. 
to decide. 



: local 



the 

itity 

Jnix identity and gtoup 



oper- 
creiateld that 



operating system identities 
operating system identiJty is 
is then associated with one 
associations. When a sei 
requdstor, it obtaihs die local operating system id^ntjlty 
obtains the list of groups a 
prcjvider then scans the access control 



these 
cltster, a local 
idebtity. 1 his local identity 
and 

it 

and from 
5 service 



identity, 
Th 



tjie underlying security mechanism, or by mapping $offware 
The (Jhoice on whjch to use is left to the component < 



To demonstrate, consider this example of a serv 
which employs access control to grant 
"greatmachine" wishes to grant the samel level 
"zathrasOl" through "zathraslO" - who fexecute 
can choose to set up an access control list that 
the same access privileges, or the administrator 
requestors. Either choice is valid, and either cho 
group approach if the list of service requestors 
very large, and the administrator wishes jto mak^ 
of group access control, the administratoir does 

• Creates a local operating systjem 
vice requestors (ex: "ctzathO^", "i 
Associates the local operating systerh 
tern user group created explicitly foi 

. Map the local operating systejm 
ties. 

Create one access control entry for 
system group name ("zathras* 0 to 



dijffering [levels of acqess 
tfeni 



CtSec provides convenience scripts and _ _ 
ties and groups, and for associating the dp 



1 . Currently, only DCE provides a mechanism to i ;roup security identities together. 
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4.2.2.1 CAUZ Configuration Information 
CtSec's CAUZ component is designed to permit 
a facility proposed for OS/400 and currently uncfer 
individual identities to identity groups for all of 
Identity Mapping is not yet a reality for AIX or 
ating system identity and group mapping mentia|aed 
designed to permit the administrator to override 
Identity Mapping. The setting of this override is 
and is only needed if Enterprise Identity Mappidg 



the eventual support of Enterprise identity Mapping, 

consideration by IBM as a solution for mapping 
BM's operating system platforms. Since Ector prise 
jnux software, CtSec chooses to usfe the local oper- 

in the preceding section. However, CtS<ic is 
his behavior by configuring CtSec to use Enterprise 
the sole configuration task needed for CtSec C|AUZ, 
is available. 



The initial release of CtSec does not define the 
specified by the version of CtSec that provides 



f >rmat of the override setting. This override ^vill be 
I nterprise Identity Mapping support. 



The CAUZ component is provided as part of the) CtSec software, and consists of code devel^pejd 
within the laboratory. 



4.3 CtSec Configuration Procedures 

CtSec requires knowledge about the system's c< 
libraries for these mechanisms an order to functibn 
nent trusted services is also required. This infon nation 
tion, a semi-manual set of procedures that occur 
officially starts. 



CtSec requires this information to be locally 
ter cannot be guaranteed to provide a default 
and access of this information, the data must 
mented procedures and a set of semi-manual 
administrator in recording the configuration 



A possible representation of a cluster if given in 
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Cluster - all nodes sharing common security mechanisms 



FIGURE 5 Example layout of a cluster and a network attached] security administration workstation. 

To configure CtSec, the following data must be 
. Identifying the security mechanisms 



the cluster must use the same securil y 
node within the cluster. The list of rJecJ 



Identifying the mechanism pluggabl ; 
anisms. Since this list of security 
of modules and libraries should 
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Identifying the trusted services withii 
trusted services shipped by IBM for 
administrator to include customer wr 
sources. 

If group based authorization is to utilized 
creation of local operating system identities 



tie 



the cluster. CtSec installs a file containing 
Clusters. This file may be modified by the sy^tejn 



From this information, the CtSec configuration procedures and utilities perform the configuration 
tasks: 
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1, 



node 



Creating entries in the configured 
security mechanisms available to the 
those mechanisms. This step involve; 
node, so the procedure must be 
should be the same for all nodes 
same set of security mechanisms configured, 

Creating security identities for the trusted 
nisms. For example, if Kerberos 5 is 
vices will require Kerberos 5 princip; 
trusted services would require the creation 



's CtSec CAUTH configuration file to indicate the 
node and the corresponding MPMs jprovide< i 1 
the modification of files local to the configured 
performed on the node being configured. This information 
wittjin the Linux cluster, since all nodes will haye tpe 



services with the configured security niecha- 
lie underlying security mechanism, ithe trus ;ed ser- 
ls to be created for them; if DCE wete emplpycjd, the 
ofDCEUUIDs. 



For most security mechanisms, this 
security mechanism's network servei , 
identities directly on the security 
the node afterwards. This server may 
attached node. To create these 
must have network connectivity to 
software for that mechanism that 
tern. 



ths 



Creating security identity groups for 
are assigned as members of security 
tributed repository. This is an optional 
authorization is desired. 



if thei 



This task does not involve the creatiqn 
mechanism's network server, even 
(such as DCE). Security identity 
local operating system identities on 
ating these local operating system 



Should the security identity groups 
and add any new security identities 
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by AIX or Linux Cluster trusted services, (the 
and groups for use in this authorization 
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lie 



involves the creation of these idehtities 
System administrators may wish to create 
mechanism server itself, and transfer thbse idenjtiti 
not be part of the Linux cluster, butirather a 
identites directly on the node being configured, 
security mechanism *s network server and 
creation of these identities from a remote 



the 



per nits < 



use in group based authorization. Security Her ti ties 
identity groups, and this information lis stored ir a dis- 
step that can be performed only if igroup bjascfd 



of security identity groups within ithe seevrity 
security mechanism provides grbup sup jot t 
grouping is achieved by associating security identi ies to 
nodes where service providers reside, and associ- 
idfntities with local operating system identity grcjups. 
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4. Creation of service keys and keyfiles 
requires that the security identities fo 

This is another task that may be preft 
the security mechanism's network sei 
to the node being configured is remoi 
ferred to the configured node. 

5. Distribution of the keyfiles for trustee 
task is performed only when a node's 
another node in the network. 

Because keys are considered sensitiv 
information between nodes is require 
structure to be operational at that tim 

The first two tasks are performed on the node be 
tion during these two procedures, convenience s< 
ing the necessary entries, using the list of chistei 

The remaining tasks in die above list can be peri 
security administration workstation, so long as tl 
are made available for general use. Convenience 
security identities and groups to make this task r 


for trusted services within the cluster. This t 
r the trusted services be previously created. 

nned directly on the node being configured 
ver. If done locally, the need to transmit the 
ed. Otherwise, the keyfile must be Securely 

services to the correct nodes withirrthe clus 
service keys and keyfiles have beeni created 

; information, a secured means for tf ansferri 
d, and this method must not require |the CtS 
J. 

ing configured. To lessen the chance* of erro 
ripts are provided to assist the admihjstratoi 
components as input. 

ormed anywhere within the cluster or on a r 
e tasks are completed before the cluster con 
scripts are also provided to assist irt the cre< 
lore reliable. 
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4.4 Functional Flow 

There are five basic functional flows during the < 

CtSec client application initialization 
CtSec client establishes itself as a sei 
Establishing a secured environment b 
Transmitting secured information bel 
Verifying authority of a service reque 

Mention will be made periodically to insecure c) 
configurations. Insecure configurations do not m 
''trusted" third party assurances that either the se 
Users in such configurations are considered to bi 
trusted services that authorize service requestors 
to unauthenticated users. Weakly secured configi 
ances alone that the parties are authentic. Some \ 
integrity of the operating system can be assured, 
that only authentic users on the Local operating s 
requestor, can be considered reliable. Other met] 
considerably less reliable and open to host "spoc 
"trusted" third party verification system cannot I 

The choice of using the default secured configur 
left to the system administrator. However, use oi 
strongly discouraged unless circumstances make 

The discussion of these functional flows will use 
ogy used to discuss these scenarios is taken from 
Serviceability Policy". The following is a short s 

External Failure The source of the 
incorrect usage of 
environments whe 

Internal Failure The source of the t 
within the source < 
ure cases as succei 

Resource Failure The source of the 
software that is no 
failures are memo: 
files, and network 


operation of the CtSec Infrastructure!: 
vice provider 

etween service requestor and provi4er 
ween service requestor and provider 
stor 

uster configurations and to weakly secured < 
ake use of either operating system absuranc< 
rvice requestor or the service provider are ai 
; unauthenticated, and to provide any servic 
must be configured to grant some ndeasure < 
irations make use of operating system basec 
issurances are reasonably reliable, provided 
Protections on Unix domain socket^, which 
/stem are accessing the socket as either pro 1 
tods, such as trusting users from kn6wn hos 
fing" attacks, but are better than nothing if j 
e installed or configured. 

ation, weakly secured, or insecure cpnfigura 
any other configuration other than secured 
it impossible or impractical to implement. 

descriptions of possible failure scenarios. 1 
the IBM Unix Development Laboratory's "! 
ummary of this terminology: 

: ailure is external to the software. This inclu 
software interfaces and execution of the sof 
re the software is not designed to execute. 

ailure is internal to the software. Thijs includ 
:ode, incomplete error checking, and treatin 
isful cases. 

'ailure is associated with a resource require* 
: under the control of the software. Example 
y allocation failures, input/output failures, i 
connectivity problems. 
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4.4.1 CtSec Client Application Initialization 
To make use of the CtSec Infrastructure function 
ture for its use. Initialization involves the creatio 
structure and the loading of the CtSec Mechanisi 
Loading these modules at this time causes the o\ 
stage, instead* of later during an authentication st 
tion. Because this data allocated by CtSec is for 1 
a handle to the data structures, which is called a s 
independent information and state information is 
of the CtSec Infrastructure MAL. 

Initialization is handled by the MAL Interface la 
the CtSec MPMs. Failure in initialization are noi 
unable to use CtSec until another initialization si 

Weakly secured clusters will load an MPM that ] 
operating system user. If the cluster is being ope 
In either case, a security services token will still 1 
the remaining CtSec Infrastructure calls for trans 
viders. 

Assuming that the development effort eliminatec 
sources of failures in this effort are: 

External Failure Incorrect usage of 

Resource Failure Memory allocatio: 
tion file missing o 


i 

s, an application must initialize the £tSec Ir 
i and setup of key data structures u^ed by tt 
n Pluggable Modules (MPMs) that fcre insta 
erhead of loading to occur during tr}e initial 
age where timing may be important jto the a 
he infrastructure only, the CtSec client recei 
ecurity services token. Within the token, me 
stored. This token is required by all other ii 

yer and the CAUTH layer. C AUTH iis used 
recoverable, meaning that the application x 
icceeds. 

>erforms operating system authentications b 
rated in an insecure mode, no MPMg will b* 
>e created so that trusted services cat contin 
tactions between service requestors knd ser\ 

! 

1 all sources of internal failures, the frnost lik 

the MAL interfaces by the CtSec client app 
i failure, module loading failure, CiiUTH c< 
• corrupted. 
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FIGURE 6 Components of the CtSec Infrastructure involved in 



Applications designed for a networked client/scifver model should continue to "CtSej: ApplicarJ 
Establishes Itself As A Service Provider" on page 28. Local system client/server application^ 
continue to "Establishing a Secured Environment Between Local Applications" on plage 38. 
tions using distributed peers that wish to authenticate their peer components should fcontinuc 
"Establishing a Secured Environment Between Application Peers" on page 36. 
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4.4.2 CtSec A pplication Establishes Itself As A Service Provider | 
Some service providers require that their clients authenticate themselves through thejuse of i third 
party that the service provider trusts. Even though the client itself may not be initially trusted, i F the 
service provider can authenticate the client using the trusted third party, the client will be considered 
trustworthy by the service provider. This method is explained in "Requestor-Provider, Third Pajty 
Brokered Authentication" on page 47. 



ns 



such 



To authenticate with trusted services within a cluster through such a third party, or tq mutually 
authenticate with applications or client users, a CtSec client application must obtain (credentials 
Some applications make use of the credentials inherited from their end-user. Other applicative: 
as trusted services which tend to be launched automatically by the system from inijt or 
have no end-user from which to inherit credentials. These applications must thereforie acquiije tjieir 
own credentials. j 



inetd 



tou 



secu- 
nkutual 
se the 



Applications obtain a security identity and security credentials in order to utilize the [underlying 
rity mechanisms. This provides the application with sufficient privilege to perform sipple and 
authentication, and to make use of the underlying security mechanism facilities. Permission 
security mechanism facilities may be required if the component design chooses to u^e a seciirit^ 
mechanism feature for associating a security identity to a local operating system identity on a rode 
for group authorization purposes. Credentials are stored in the process's private data! structures that 
are used and maintained by the operating system. I 



CtSec CAUTH is used to obtain this permission to use the security mechanisms and 
dentials. CAUTH instructs the MPMs for each security mechanism to obtain credentials for 
cific security mechanism. This process is initiated by the CtSec client application, u^ing the 
interface for establishing a service provider. 



permission is 
Converts this step 
for 



In insecure and weakly secured clusters, no security mechanism is configured, so no 
needed to use an underlying security mechanism. In effect, the CtSec Infrastructure 
in the process to a no-op. This permits a service provider to utilize the same code path for both 
secured and unsecured clusters. When operating in insecure clusters, all service requestors will 
appear to the service provider as unauthenticated users. Any service provider attempting to ^utijiorize 
a service requestor must be capable of granting access to unauthenticated users 



Internal sources of failure should be eliminated during the implementation and testhjg efFortjs. 1 
ble sources of failure at this level include: 



External Failure 
Resource Failure 



provi 



Identification failure (incorrect service name or servicp key 
interface usage failure 

CtSec CAUTH configuration file missing or corrupted, MFM 
loading or location error, security context memory allocation 
security context creation failure (data not accessible fijom MAjL) 
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FIGURE 7 Components of the CtScc Infrastructure involved in trusted service establishment 
4.4-3 CtSec Application Est ablishes Itse lf As A Service Requestor 

Some service providers require that their clients authenticate themselves through thd use of k third 
party that the service provider trusts. Even though the client itself may not be initially trusted, if the 
service provider can authenticate the client using the trusted third party, the client will be co isi iered 
trustworthy by the service provider. This method is explained in "Requestor-Provide^, Third Paj-ty 
Brokered Authentication" on page 47. 
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In order to make use of the trusted third party, the service requestor must first verify 
third party — the security mechanism — that it is authentic. This is done by "logging 
lying security mechanism, by identifying itself as a party that the security mechanism 



to the trjustled 
in" to 
already 



CtSec CAUTH is used by service requestors to identify themselves to the underlying security mecha- 
nisms. The application invokes the CtSec MALI routine provided for service requestors to establish 
their security identity. When successfully completed, the application will have established both its 
identity and credentials for using the security mechanism to authenticate itself with a service: pio- 
vider. CtSec CAUTH invokes the MPMs for all available security mechanisms, instrjicting these 
modules to obtain the security identity and credentials for this process for that specific securi ty mech- 
anism. This information is stored in the memory location referenced by the security Services token 
that was established previously. 



In both insecure and weakly secured clusters, the CtSec Infrastructure will not obtain a secu it) 



for both 



se 



tity for the application. This permits the service requestor to use the same code path 
and unsecured clusters. The service requestor will possess the same privileges as an unauthe|nti|;ated 
user in an insecure configuration. Weakly secured configurations will make use of th 
requestor's operating system user identifier for authentication purposes. 



e service 



i 



Internal sources of failure should be eliminated during the implementation and testhjg efforts 
ble sources of failure at this level include: . 



External Failure 



Resource Failure 



Identification failure (incorrect service name or servicp key prpvip 
interface usage failure 

CtSec CAUTH configuration file missing or corrupted, MPM 
failure, security context modification failure j 
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RGURE 8 

4.4.4 Establishing 



Components of the CtScc Infrastructure involved with service requestor establishment 

a Secured Environment Between Service Requestor and Prouder 



3\|iC 



Once an application has obtained credentials, either by using the credentials established by its dnd 
user or by obtaining its own credentials via CtSec, the application can attempt to authenticate 
with another application or trusted service. Once this authentication succeeds, a secujred 
is established between the application — as service requestor — and the service provider. This 
ment is named the security context. Once the security context is established, the service 
service provider remain authenticated for the duration of the context. Should the context 



: requester 
; expire 
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connection established between provider and requestor be dropped, a new authentication is rjeqijiired 
to establish a new security context. 



Authentication is a "hand shaking" process which requires the requestor and the provider to 
the security mechanism they will use, and to agree that both parties are trusted by th<! seci 
nism. 



agjee 



untp 



time 
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FIGURE 9 Requestor-Provider Authentication Flow, Single Authentication Model 
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CtSec's CAUTH component provides the utilities for both service requestors and service 
perform these authentication tasks, for both single and mutual models of authentication. 
CtSec's overall goal of abstracting the security mechanisms used by the system froir the 
requestor and provider alike, CAUTH determines what security mechanisms are ava lable, v, 
ones to select both during provider reconciliation, and ultimately which mechanism will be 
upon as the one to be used for these parties. 
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FIGURE 1 0 Components of the CtSec Infrastructure involved in establishing a security context 



For the service requestor, CAUTH abstracts the instructions required to obtain the list of 
mechanisms supported by the client's system. This information is returned in an opaque dati 
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ture, which the requestor can then transmit to the service provider. This data does not requir£ encryp- 
tion, since the information itself is not protected. 

The service provider reads the opaque data structure, and in turn uses C AUTH routim ss to pei foi m the 
security mechanism reconciliation; CAUTH examines the list of security mechanisms, compares it to 
the security mechanisms supported by the server's own system, and returns an opaque data structure 
that contains the list of mechanisms common to both systems. The service provider is not unsolved in 
the reconciliation process, CAUTH obtains the information it requires from the CAUTH cor figura- 
tion information. The provider then transmits the opaque data structure to the service! requestor. Since 
this information is not protected, it can be transmitted without being encrypted. 

Upon receipt of the reconciled security mechanisms, the requestor uses CAUTH routines to s sle :t one 
of these mechanisms and to obtain the requestor's credentials associated with that mechanism, rhe 
requestor makes no explicit selection of what mechanism to use; CAUTH makes thii decisio n. Cre- 
dentials are obtained using GSSAPI routines associated with the security mechanisnji ehoser by 
CAUTH, packages in an opaque data structure, encrypts the buffer in a manner that ian be decrypted 
by the service provider, and provides this buffer to the requestor. The requestor must then trai|isn|nt the 
opaque data structure to the service provider to authenticate the requestor's identity. I 

At this point, a security context exists for the requestor, but not for the provider yet. k handlb isf pro- 
vided to the requestor, called the security context token, which must be provided to f ny CtSt c T AAL 
calls the requestor uses to communicate with the service provider. The context contains information 
on the mechanism being used for this security context, including keys to be used for|encryptjin§ and 
decrypting data transmissions in the future. I 

After receiving and decoding the requestor's credentials buffer, the service provider invokes CAUTH 
routines to extract the credentials from this buffer and authenticate the requestor usin ; the m^ch^nism 
selected by the requestor. j 



i point, 



to 



iCtSec 



pro- 
nletes 
the ser- 
MAL 



In single authentication models, a security context is established for the provider at t lis 
vided that the security mechanism successfully authenticates the requestor's identity, This com 
the setup of the security context between the requestor and the provider. A handle is given 
vice provider, called the security context token, which must be used by the provider i i an 
call to communicate with the requestor. The context contains security mechanism specific irifoifma 
tion. After this point, the requestor and the provider may commence their transactions in a : 
authentication model. However, these parties will not be able to encrypt and decrypt data betwden 
them unless they share a common secret key, or unless both parties decide to mutually authepti ;ate 
with each other. 



In mutual authentication models, the service provider must repeat the steps perforauKl by thi sdrvice 
requestor, obtaining credentials for itself and transmitting these credentials to the serrice requestor so 
that the requestor can validate the provider's identity. As with the requestor's case, Cf AUTH Jautjornat- 
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ically obtains these credentials from the correct mechanism, packages them in an opaque struct ire, 
and returns the structure to the provider. As is also the case with the requestor, the provider e stab- 
lishes a security context at this rime, and the provider will use the handle to this cont sxt in future 
CtSec MAL calls during its transactions with the requestor. Unlike the single authentication nicdel, 
the setup of the security context is not complete. The provider must transmit the opaque data structure 
back to the requestor, so that the requestor may authenticate the service provider. 

After receiving the provider's credentials buffer, the service requestor invokes CAUTfH routihesj to 
extract the credentials from this buffer and authenticate the provider. A security context is established 
for the requestor at this point, so long as the security mechanism successfully authenticates the pro- 
vider's identity. This new context must be used in place of the context formerly estat lished for lie 
service requestor; the old context is to be discarded by the requestor. This completes the settp of the 
security context between the requestor and the provider fn a mutual authentication model. A handle is 
given to the service requestor, called the security context token, which must be used |>y the requestor 
in an CtSec MAL call to communicate with the provider. Both the provider's and th« requestor 
security contexts will contain the keys necessary to transmit and receive encrypted ii*formati|on 



To send encrypted data between a service provider and a service requestor, both the Client an d 
requestor must mutually authenticate. j 



use 



In weakly secured clusters, both the service requestor and the service provider agreelto use 
operating system's assurances instead of a "trusted" third party to authenticate the idlentity ofth(e 
other party. In practical terms, both the requestor's and the provider's systems are co[ifigurec 
only the operating system to assure authenticity. The CtSec Infrastructure makes use |of the provider's 
and requestor's operating system identity instead of credentials. When both the provjder and 
requestor are guaranteed by the operating system to reside on the same node, the flo>(v descri 3ed 
"Establishing a Secured Environment Between Local Applications" on page 38 is us^d to obtaiii 
assurance. When this assurance cannot be provided, the remote operating system is contacte i 
requested to verify the identity of the remote party. This assurance assumes that bothlthe netwoiik 
the remote operating system can be trusted, and such assurances are minimal unless the 



the nodes are physically isolated. 



i 



t networ c 



Simple and mutual authentications are a formality in insecure clusters. A security context tol&n is 
always established, but no session key is established for the context Requests to enctypt dati for 
secured transmission result in a "clear" message being returned to the caller, and decjoding tl eso mes- 
sages on the other side of the connection results in merely extracting the "clear" message. Sorv ce 
requestors and service providers are oblivious to this, since they continue to use the sjarne Ct§ec Infra- 
structure routines for secure data transfer in both secured and unsecured clusters. ! 



Failure scenarios in this model include: 
External Failures (Requestor) 
External Failures (Provider) 



Usage failures in CtSec MAL calls 
Authentication failure of requestor on provider 



cnlv the 



in 
this 



and 



and 
and 



s system 



4/1 a/1 



IBM Confidential 



fnflow.chp 



35 



PACE 95/128 * RCVD AT 5/15/2006 3:44:56 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-6/27 * DMS:2738300 • CSID:518 452 5579 * DURATION (mm-ss):50-50 



05/15/2006 16:25 FAX 518 452 5579 



HESLIN ROTHENBERG 



-> USPTO-RESPONSES @] 096/128 



Resource Failures (Requestor) 



Resource Failures (Provider) 



Inability to obtain credentials from underlying feeclurity 
mechanism, no common security niech uiisms betjveen 
provider and requestor, authentication fjailure o 
requestor on provider's system, mutual 
failure of provider on requestor's systeii, memory 
cation failure on requestor, memory allocation ffrilijire 
provider 

Inability to obtain credentials from underlying 
mechanism in mutual authentication cases, autl|ien|tica- 
tion of provider on requestor's system i 
tication models, memory allocation fattjure 
memory allocation failure on requestor 
authentication models 



authentication 
allo- 
on 

security 



4.4.5 Establishing a Secured Environment Between Application Peers 

Not all authentication requires the use of a trusted third party. Some distributed components of |the 
same application make use of a common, shared secret key. Knowledge of this key i:; sufficient 
to one component of the application that the other component is trustworthy. This mptbod re|mc}ves 
the need to use a trusted third party, so these components would not need to obtain 
and credentials for use between their own components. However, such applications 
rity mechanisms to encrypt and decrypt information using keys. This method is explained in|m<t)re 
detail in "Daemon-to-Daemon, Common Secret Key Verification Authentication" on page 45! 



In this method, each component within the application has access to the same commpn, shared feecret 
key. CtSec provides a means for the application to obtain its correct secret key. CtSe : also ensures 
that the keys are kept current for the application, and that the application always has access to t le 
most current and the next most recent keys. The CtSec MAL will determine if new keys neeJ to be 
obtained and which key needs to be used for deciphering incoming data as a natural course of t le 
interfaces for sending and deciphering data. The application does not need to perform its owd key 
management; this task is assumed by the CtSec MAL. The component design will demonstrate how 
this is accomplished by the CtSec MAL. 
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L require 



for the 



CtSec will permit these components to encode and sign messages using the key, and 
components to decode and verify these messages. Applications invoke the CtSec MALI routine 
either encode or decode messages, and the CtSec MAL responds by invoking encryption roijtin 
available in the operating system to perform these functions. DES and Triple-DES ai e 
such encryption software. 



Establishing a secured environment through this method does not depend upon the presence of 
trusted third party such as Kerberos version 5. Therefore, this method can be employ ed even in 
weakly secured and insecure clusters, provided that some sort of encryption software such a* DfeS or 
Triple-DES is installed on all nodes in the cluster. If no encryption software is availa Die, the [CtSec 
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Infrastructure simply returns the "clear" form of the original message. Decryption of 
also becomes a no-op, and verification of data signatures are always successful. 

Internal sources of failure should be eliminated during the implementation and testirj 
ble sources of failure at this level include: 

External Failure MAL interface usage failure 

Note that CtSec will be unable to detect whether the "correct" key has been used to i 
decode the information. If the application uses the wrong key with the CtSec MAL r 
will be unable to detect this. Verification of the data is the responsibility of the appli( 
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FIGURE 11 Components of CtScc involved in common secret key based authentication 

4.4.6 Establishing a Secured Environment Between Local Applications 



can 



Another authentication model that does not require the use of a trusted third party 
between a service requestor and a service provider when both parties are guaranteed 
on the same system. In these cases, the operating system's assurance that both partie 
is sufficient to trust the other party. Encryption and decryption of information can 
both parties use a private communication mechanism that cannot be simultaneously 
process, such as a Unix domain socket connection between requestor and provider. This metjho^ id 
explained in "Operating System Based Authentication" on page 48. 
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Because this model does not require the use of the underlying security mechanism n< 
tion library, the CtSec component is not required to provide special function for appl 
this method. For application convenience, CtSec does provide MALI routines to set i 
Unix domain sockets that are primarily used in these scenarios. 

Because this method relies on the operating system to prevent misuse of the Unix doj 
method of establishing a secured execution environment is always available from the 
structure, even in weakly secured and insecure cluster configurations. 

Failure scenarios in this model include: 

External Failure MALI usage failure, insufficient permission to access 
socket 
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FIGURE 12 Components of CtSec involved in operating system based authentication 

4.4.7 Transmitting Secured Information Between Service Requestor and Provid 



After authentication has been performed and security contexts have been established 
requestor and the service provider, both parties are considered to be authentic system 
begin transacting business between them. These parties may need to transmit information bejtw^en 



1. These contexts are established using one of the mechanisms described in the three preceding seel ions. 
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them that must be protected from use or examination by other parties which may be < 
the connection or intercepting the traffic on the connection. To prevent use of sensit 
from such nefarious external parties, the requestor and the provider can choose to ei 
mation in a manner that only they can decrypt. 

CtSec provides two methods for processing data for secured transmission: 

♦ Security Context Based Encryption. This method uses keys stored in the 
for both the service requestor and service provider to encrypt and decryp 
CtSec MAL uses information stored in the security context data structun 
decrypt the information. Providers and requestors simply call the CtSec ] 
either encrypt or decrypt the information, providing the security context 
the argument to the call. 

• Private Key Based Encryption. This method uses a common, secret share 
the requestor and the provider share. How these two parties came to shai 
key is not the concern of CtSec; both parties used Some Other Means to 
The encrypting party provides the data stream and the common, secret shi 
encoding the data stream. The decrypting party provides the encrypted da 
same common, secret shared key. 

Because the methods differ, two separate sets of interfaces are required for encrypti< 
vides one pair of interfaces for security context based encryption, and a different set 
private key based encryption. Both sets of encryption routines use any available libr 
encryption and decryption of the data. Examples of such software include DES and 

Private key based encryption is available in secured and unsecured clusters, provide* 
software such as DES or Triple-DES is made available on all cluster nodes for the C 
ture's use. 

Security context based encryption is not available in weakly secured and unsecured c 
this fact is hidden from the CtSec Infrastructure client. Service requestors and servu 
the same CtSec Infrastructure routines to prepare and process data in either case. Th 
structure will determine that the cluster is insecure, and forgo the encryption and de< 
message. 

The CtSec Infrastructure only encrypts and decrypts the data; it does not transmit th 
the other party. The CtSec client is still responsible for the transmission of this infor 
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FIGURE 13 Components of the CtSec Infrastructure involved in encryption and decryption of secured informatii in 



Failure detection during the encrypting or decrypting procedure is rather limited. Th 
incapable of detennining if the "correct" encryption key is provided by its caller, or 
in the security context is making use of the correct keys in either encryption or 
information. Therefore, final assessment on how "correctly" the encryption or 
mation was performed is left to the service provider and requestor to determine. Failu 
can be detected are: 

External Failure Incorrect usage of CtSec MAL interfaces 
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Resource Failure Memory allocation failure, DES encryption or decryp 
4.4.8 Verifying Authority of a Service Requestor 

On occasion, service providers may wish to restrict certain function or resources fro 
granting full or partial access to a subset of valid system users and trusted services, 
being an authentic system user or trusted service, the requestor must also meet specif 
which are granted based on the user or trusted service's identity. In other cases, resoi 
may instead be restricted from selected users or trusted services, while access is gra 
authentic users and trusted services. Service providers use access control to protect ! 
and functions. Access control is traditionally granted using two basic schemes: 

Granting or denying access based on the requestor's identity 
Granting or denying access based on the requestor's group association. 

The first method is rather simple, straightforward, and supported by most security n 
service provider maintains a list of those users and services who are granted (or den 
resource or function that the server provides. While simple, this strategy becomes a 
administer in large systems with many users or trusted services and many resources 
control. Performance is also impacted in such environments, where access control cl 
a factor of system's size and the user community's size. Also complicating this appr 
dency for different security mechanisms to provide differing solutions to individual 

The second method is supported by some security mechanisms: users and trusted se 
assigned to membership within specific user groups, and group membership become 
cess's identity much as the user's identity. Instead of maintaining a list of all possibl 
vice provider maintains a list of the groups supported by the system to which it will 
Instead of looking for the user's or service's identity before granting access, the usei 
group membership is examined, and access is granted or denied based on that memt 
control checking is more scalable in this approach, but not all security mechanisms j 
membership assignment of their security identities. 

4.4.8.1 Identity Based Authorization 

To grant access based on identity, the service provider must decide what resources or 
trols, determine which ones require special access, and create an access control list ( 
this list. 

4.4.8.2 Group Based Authorization 

Because security identity grouping is not a feature supplied by all security mechanis 
vides its own scheme for providing group access through the use of Unix operating & 
identity groups. In cases where the underlying security mechanism does provide a gi 
CtSec will not exploit it. This allows CtSec to avoid possible assumptions that are m 
cific from surfacing in the mechanism abstract group mechanism provided by CtSec 
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4.4.83 Authority Verification in Weakly Secured Clusters 

The requestor's operating system identity is used to verify the requestor's access in 
clusters. In these clusters, the access controls maintained by the service providers rr 
operating system identifiers. 

4.4.8.4 Authority Verification in Insecure Clusters 

In insecure clusters, all service requestors will appear to the CtSec Infrastructure cli 
cated users. All unauthenticated users are handled the same way in authorization ve 
granted whatever level has been granted to the general classification of unauthentic* 

System administrators need to understand the nuances in this case. In effect, insecur 
the service provider's capability to grant differing levels of access to different users, 
applications that use access controls must allow access to unauthenticated users, an< 
this class of user full access to the service. If no entry exists in the access control list 
ticated user class, all users will be denied access to the service in an insecure cluste: 

System administrators must also realize that the access controls need to be revised i 
migrated from insecure to secure. The full level of access should no longer be grante 
ticated users in this case. Such a migration will necessitate shutting down the trustee 
fying the access controls to remove full access from unauthenticated users, and rest* 
services. 
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FIGURE 14 Components of the CtSec Infrastructure involved in authorization processing 
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5,1 Considerations in Secured Executions Environments 

Implementing a secured execution environment involves authentication of service 
enforcing access control on resources controlled by the trusted services to prevent 
rized service requestors. 



requestor's 
apcess by 



5.1.1 Auth entication 

Authentication is the task performed by service providers to ensure that the service 
ognized system service or system user, instead of a rogue party seeking access to sy 
and function. 



requestor if; arec- 
stem resources 



Trusted services use several programming models for authenticating service providers and slenfice 
requestors. These methods tend to be based on common communication protocols v sed bet\ veen the 
parties, although any model could be used in any communication protocol. The moie comnjon meth- 
ods used in Linux cluster and SP software are described below. 



5.1.1.1 Requestor-Provider, Third Party Brokered Authentication 
Requestor-provider authentication requires the service requestor to authenticate itsel 
provider before requesting functions or resources controlled by the provider. Because 
this exchange is completely trusting of the other, a third party trusted by both is used 
authentication 1 . The model also allows for mutual authentication, where the service r 
demand that the service provider also authenticate itself before the requestor accept! 
function. To perform authentication in this model, trusted services and their client a] 
consider the following: 



Include logic to start the CtSec security services, use CtSec to obtain the tiusted iserlvice's 
security identity and credentials, and perform CtSec termination and cleaj nip Iogi : p rior to 
termination of the trusted service. 

Include flows in their communication protocols to accommodate the passing of sbcitrity 
context data between the service requestor and the trusted service. 



unaithmti 



If a trusted service is unable to authenticate the service requestor, the connection to the service 
requestor should not be dropped. Instead, the service requestor should be considered 
cated client, and the trusted service should continue to process the request. It is valid 
services to grant some degree of limited access to unauthenticated users, and some 
will permit access to resources and function for such users. 



Security mechanisms are essential to this method of authentication. It is the security 
vide the identities used by the parties in this authentication method, and provide the 
the identities can be verified. Users of this authentication method are therefore 
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1 . Examples of such third parties arc Kerberos version 5 and DCE. 
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CtSec services for obtaining their security identities and credentials, and to verify tt 
the other parties in the negotiation. 

5.1.1.2 Daemon-to-Daemon, Common Secret Key Verification Authentication 
The preceding paragraphs assume a traditional client and server execution environn 
third party to broker authentications. This is necessary because the client and server 
ent applications, and neither can be assured of the identity of the other party withou 
from a "trusted" third party. Not all secured execution environments follow this mo< 

IBM Linux and AIX clusters provide distributed subsystems that act as trusted servj 
vices are implemented as daemons that execute on all nodes within the cluster. In es 
application executes on each node. To provide their service to their clients, these dis 
often need to work together, with a daemon on one node making requests of its cour 
nodes in order to complete this function. These daemons still need to verify the idee 
party to ensure that another application is not attempting to misuse the service, but £ 
party is not necessarily required in this case. So long as all the distributed daemons c 
vate means for identifying themselves, and in a manner that cannot be imitated by o 
tions. This model is typically labelled daemon-to-daemon authentication by the clus 
services. 

Typical implementations of this model utilize a common secret key, of which all ins 
mon are aware. This common secret key is used to generate a message digest that is 
the message to the other instances of the trusted service. If the digest is successfully 
ified by the receiving party using the same common secret key, the transmitting part} 
be authenticated by virtue of its knowledge of the secret club handshake. 

Security mechanisms are involved in this authentication method to the extent that th 
common shared secret key used by the daemons. Applications using this method us* 
faces to acquire the common shared secret key and rely on CtSec key management t 
from expiring. 

A problem inherent in this authentication method is the special processing that must 
common shared secret key is updated. This key has to be updated before it expires. ( 
designs will deal with the management and maintenance of these keys. 

5.1.1.3 Operating System Based Authentication 

This model employs the operating system's assurance that both parties attempting to 
secured execution environment are authentic. No external verification of either party 
rity service is requested. 

One such authentication scheme present in all security configurations 2 uses Unix doi 
assure that both parties are authentic. In this model, a service provider establishes a \ 
socket (UDS), which is only accessible to processes executing on the node; it is not \ 
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externa] application to access the socket. If the owner of the process possesses sufficient 
access the node, the service provider considers the requestor authentic. To help keep 
and other riff-raff, privileges are usually set quite high on these sockets so that only 
set of users -such as root only -- can access the socket. Although this method 
weak, it does improve performance by removing the need for an additional security 
involved in the transaction between requestor and provider. The weakness is in 
system's integrity, but this concern is offset with the knowledge that if the root user 
then there's a far greater security risk on the system than accessing a trusted service 



out < 
a very] 
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service 1 
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is compromised. 
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Another authentication scheme makes use of operating system network services to a 
of parties connecting to a socket from a remote host. In this model, a service provid 
operating system identity and the host address source of the connecting requestor, 
verified and checked against a predefined list of trusted network hosts. If that test is 
tity providing service ~ such as identd — is contacted on the remote host and asked 
authenticity of the connecting party's operating system identity. At the successful 
tests, the connecting party is considered to be authentic. This protection is only as 
trust that can be placed in the network and in every system operating on that networ c 
and its systems are not physically isolated, this scheme is susceptible to host address 
attacks. 
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5.1.2 Access Control 

The implementation of access control may differ between the trusted services, becaikse in thje initial 
Linux cluster software release, CtSec will not provide access control list (ACL) storage facilities. 
Any trusted service that implements access control is responsible for developing a njiecbanism \o 
store the ACLs it uses and load these ACLs during their startup procedures. 

5.1.Z.1 Common Characteristics of Access Control 

All access controls have common characteristics which all trusted services can expefct. 
5.1.2.1.1 Association With Specific Functions or Resources 

An access control list is associated with a specific resource or function. Any time a Service rfeqiiestor 
attempt to access the resource or function, the trusted service is responsible for verily ing th£ t die ser- 
vice requestor is permitted access to the resource or function by examining the ACL. Usually, in 
access control list is specific to an instance of a resource or function, or specific to a common group 
of resources or functions. Different resource and functions can ~ and often do — hav^ different Hccess 
control lists. 



5.1.2.1.2 Describes Degree of Access Permitted to the Function or Resource 
Access control lists specify the degree of access permitted to the resource. Degrees 
no access, to full access, and to degree in between these two extremes. Customary i 



2. These configurations — secured, weakly secured, and insecure — were introduced in "Functional Flow** on page 25, 
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include: read access, write access, creation access, deletion access, administration afccess, aAd bthers. 
Some, all, or none of these degrees of access may be granted for a resource or function. It is the 
trusted service's responsibility to determine what level of access should be granted jo its functions 
and resources. 



5.1.2.1.3 Associates a Degree of Access To Specific Users and Services 

Access control lists associate a degree of access for the resource to specific security) identities 
general classes of service requestors. This means that an entry in an access control list will 
that a user, application, or group of users has a specific set of access rights to the rei ource 
contains one entry per user, service, ot group. This permits the service provider to grant the differing 
levels of access mentioned above. 

An example of such a scenario is shown in the following diagram. 
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FIGURE 1 5 Clients requesting resources from a trusted service that uses access control to determine access 

In this example, the trusted service granted service requestor One full access to the 
trols when the trusted service set up its access controls. Service requestor Two was 
limited set of access, but more access than any other authentic system user or any 
system user (which has the least degree of access in this example). When service 
attempts to access the resource to perform administrative functions on it, the trusted 
the access control list to determine if this access was granted to Two. Detennining 
access was not granted, the trusted service denies this request from Two, but would 
such access for One. 



thit 



5.1.2.2 Security Mechanism Considerations 

Access controls are granted based on the security identity of the service requestor. These seduri'ty 
identities are specific to the underlying security mechanism which is used to provide that identity. 
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However, the trusted service has been abstracted from any knowledge of the underlying selcujkty 
mechanism. It is not possible for the trusted service to know what security mechaifism wasf u^ed to 
generate the security identity of the service requestor 



If the set of security mechanisms in use by the Linux cluster should change for soihe reascjn, 
service access control lists must be examined. System administrators must ensure t 
trol lists maintained by the cluster component trusted services are updated to includ 
identities that had to be created in the new security mechanisms for existing users 
Trusted services will be unable to perform this modification on their own. 
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Consider the example given in the diagram on page 50 again. If the underlying , 
were modified to include a new security service called Kerberos Global Bastion 
that service requestor One will need a new security identity to use with the new 
ComradeOne. Should service requestor One establish its identity as ComradeOne, 
will not grant it One's level of access, but instead grant it AnyAuth's level of access 
ComradeOne the level of access it deserves, the access control list used by the trust* 
updated to include One's new security identity and to specific One's level of access 

Entries do not need to be removed from access control lists when security mechanibms are 
although a system administrator may choose to do this to improve the overall performance 
control list entry searching. 
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Reasons for choosing this design approach have been discussed in earlier sections o 
They are summarized here for reviewing purposes. 

9.1 Reduce Development and Service Investment 

For all security mechanisms, the general tasks for applications and services need to j 
a secured execution environment and protect resources are usually the same: agree c 
authenticate the parties, authorize the parties, grant or deny access, and protect infor 
dental or intentional interception. The specific instructions required for each mechai 
plish these tasks tend to be quite different. If the security mechanisms cannot be abs 
applications and services must either provide multiple code paths to perform these ft 
what mechanism is in use, or must provide differing binaries that are specific to the 
nisms. 

To provide a more generic security programming model, an abstraction layer is requ 
tion layer can handle the security mechanism specifics, while presenting generalizcc 
applications and services to use in accomplishing the general tasks required by all s< 
nisms. This reduces the development time required of all the Linux cluster software 
concentrating the mechanism specific calls in one component which the others explo 
also reduces the chance of failure injection in security related software by conccntra 
of the security mechanism interaction in one component; if all components impleme; 
of software, failures could be injected in the source code of all components. Develop 
costs are expected to be reduced in this approach. 

Development and service costs are also reduced in this model, because it is no longe 
modify trusted service or application code whenever a new security mechanism is si 
platform. In traditional security coding, the test for configured security mechanisms 
extended, and a new code path would have to be inserted for the new security mecfa 
abstracting the mechanisms to a lower layer of software, applications and trusted sen 
to modify their source code in mis case. Code modification is restricted to the mech* 
dent layer. 

9.2 Foster Development of Common Code 

By removing the need for applications and trusted services to understand the differei 
security mechanisms, this approach makes it possible for applications and services t< 
code path to create and use a secured execution environment. The need to detect the 
mechanism and the need to write mechanism specific code is removed, making it po 
same source code instructions regardless of the platform or the security mechanism i 
code is further fostered through the CtSec interface, which is designed around the ge 
performed, not the security mechanism specifics. 
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This approach also provides common handling of basic failure conditions applicatk 
would encounter in its dealings with the underlying security services. Handling of ru 
cases such as invalid parameters, failed resource allocation, and so forth failures s 
looked by applications and services that expect all resources to be available all the t 
trated in the CtSec component. This helps to ensure that all basic failure cases are d 
trapped, and removes the need for applications and clients to implement checks for 
ure conditions. 

9.3 Allow Customer Selection of Desired Security Mechanisms 

Linux clusters are expected to be introduced to existing computing installations, ins 
existing computing installations. Existing installations have already chosen a securit 
security administration model, and the Linux cluster should be designed to fit into ti 
of imposing a model on the existing installation. Since the SP represented a signifies 
and tended to be a self-contained unit within the IT installation, SP could afford to i 
security model on itself. Linux represents a smaller customer investment using com 
and open source software, and customers expect the solution to be flexible. Therefoi 
ter offering should be flexible in the security mechanisms it supports. 

The initial offering of Linux cluster software from this laboratory will not complete 
goal, restricting the security mechanism to Kerberos version 5. However, the design 
to allow for easy future support of further security mechanisms, and permits the cust< 
mechanisms that will permit the Linux cluster to fit into their existing IT installatior 

To allow the customer to select from multiple security mechanisms, applications an< 
must understand and handle multiple security mechanisms. If the applications and s< 
required to write mechanism specific code to accomplish this, the security mechanis 
supported would be restricted to the set supported by the most restrictive service. In 
one essential trusted service supported only Kerberos 5, the only possible security n 
in the cluster would be Kerberos 5, until such a point as that one trusted service is mc 
further mechanisms. This would also mean that the trusted services and applications 
modified to understand the new mechanism and to provide a new code path for its ui 

CtSec abstracts the underlying mechanism, removing the need to modify the service 
code to support new mechanisms. Support of the mechanism is left to the CtSec mec 
tion layer. This permits any binary using CtSec to execute in any environment and ui 
mechanism supported by CtSec, removing any constraints placed on the choice of s* 
nisms from an application or trusted service point of view. 

9.4 Permit Reconfiguration of Security Mechanisms 

Administrators may choose to alter the security mechanisms used in their IT installa 
reasons: one mechanism has been compromised, a mechanism has been configured ii 
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injecting failures, or a mechanism is no longer required. Not only does the security Infrastnlctilre 
need to permit changes in the set of security mechanisms used, but the applications and trustee ser- 
vices also need to support such changes as well, even if this support amounts to a restart of the soft- 
ware. 



Applications and trusted services inherit the ability to permit security mechanism cHanges ffcorii 
CtSec mechanism abstraction layer. Since applications and services do not directly interface with 
security mechanisms, they no longer impose a restriction on changing the underlyin 
nisms. These mechanisms can now be changed, and the applications and trusted ser 
capable of continuing their function. 
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CtSec is capable of detecting when a security mechanism is no longer in use by exainining 
information from the underlying security mechanism's library interface. Instead of lequirinj; 
application or trusted service to halt and restart, CtSec informs the client that its cre dentials 
longer valid and must be obtained again. Properly coded applications and trusted sa vices shoulld 
already be designed to expect such an occurrence, and will handle the event in accordance \yitL 
existing credential expiration logic. Applications and trusted services are no longer 
out" of one path of mechanism specific code, rediscover the mechanisms currently 
a different code path for a different security mechanism. 
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9,5 Facilitate Porting of SP and Cluster Software to Linux Cluster 

IBM's key to success in the Linux market is to bring its current ATX based cluster software 
neered to provide enterprise level function to a Unix based distributed operating sys em - tv b$Bi on 
the Linux market If the expected growth rate of the Linux market holds true tQ ] 
customers will soon find the difficulties in clustered environment that IBM has i 
with the SP, and seek to find SP styled solutions for this market as well. To be ready 
ability to quickly port existing SP components and AtX cluster components to the Lftnux i 
form. 



SP cluster software makes use of the PSSP Software Security Subsystem (S3), whic l 
vide an interface independent of the underlying security mechanism. Although there 
with providing the exact S3 infrastructure in the Linux environment 1 , the security i 
tion should be similar in its coding model to the existing S3 interfaces. 



For this reason, this design mirrors the S3 programming model to a great degree. Interface ninis and 
signatures have been modified, but the general interface flow remains the same. Con ponenfe i boing 
ported to the Linux cluster should expect a minimal impact of porting to the CtSec iifrastru^tuie 
interfaces. 
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1 . Sec "Porting of PSSP S3 Component To Linux" on page 84. 
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11.0 Scaling Considerations 
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The security infrastructure implemented by this design takes the form of a shared li 
tributed subsystems that require inter-node communication in a cluster, the CtSec lil 
with services on the local node only. Since no inter-node communication is added to 
by the CtSec design, the addition of CtSec to the Linux cluster does not immediate! 
ability of the Linux cluster software. 

11.1 General Scalability Issues With Security 
11.1.1 Authentication Scalability 

CtSec places the scalability burden on the underlying security mechanisms. These n 
require inter-node communication to obtain credentials and verify identities. The res 
ensuring that the underlying security mechanism can scale to systems the size of the 
cluster is left to the security mechanism provider. Since CtSec acts as a client of thes 
cannot improve the scalability situation for them. The scalability of CtSec is direct!) 
scalability of the underlying mechanisms. 

Should scalability of the underlying security mechanism pose a problem, the ability 
alternate security mechanisms can help address the problem. Should other security m 
more scalable than the original Kerberos version 5 mechanism, CtSec can be easily 
more scalable mechanism. 

IhUZ Authorization Scalability 

Access control implementations are directly affected by the size of the Linux clustei 
vices added to the cluster, the more security identities that exist. The same holds tru< 
nodes are added to the Linux cluster, since one security identity will exist per servic 
cluster. Should a trusted service use access control, ACLs can grow quite large if the 
trols are based solely on identities, for the list will have to contain one entry per ident 
(or denied) access. Obviously, larger ACLs will require more time to search, which < 
cause timing related denial of access problems. 

To address this problem, CtSec provides a security mechanism independent security 
ing scheme to be used in access controls. By assigning common security identities t< 
controls can be granted on a group basis. Instead of creating one entry per identity, A 
an entry per group. Using group based access should keep ACLs to a consistent size 
size of the Linux cluster. 

Security identity grouping is available only when LDAP is used to administer user a 
Linux cluster, and when all nodes in the cluster have access to a distributed LDAP re 
is not the case, access controls are forced to be granted (or denied) on an individual i 
which leads back to the original scalability problem. 
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Scaling Considerations 



System administrators need to be aware of the potential access control scaling problem whejn plan- 
ning the Linux cluster, and include this in their decision when considering using LQAP for jisqr 
account management 



11.2 Scaling Design Point for this Design 

Although this solution is originally offered for the Linux cluster environment, the SI' 
design points have been used in developing the design. Fortunately, this is a relative 
to make since CtSec depends on the underlying security mechanisms to scale to the; e envirinriients 
CtSec *s implementation should not differ in small or large cluster configurations, an|d the cu|rre 
proposed implementation should function equally well in small and large clusters. 



11.3 MP Enablement 

The CtSec Infrastructure library uses threads in its implementation. The library relic s on the ur derly- 
ing operating system to efficiently schedule and dispatch these threads. Any multiprocessor capability 
within CtSec is directly dependent on the multiprocessor capability of the Linux operating system. 



11,4 Large N-WAY RPQ Systems 

This design relies on the underlying security mechanisms to scale to whatever node J 
Linux cluster. This applies to RPQ systems as well. 



Large RPQ systems should be required to use LDAP for user account management, to permit 
control scaling to large clusters. Without this, group based access control is not possible. Inc ivi 
based access control will be monstrous to set up and maintain in such an environment, and ti|ie 
mance of access control verification will be poorer. 
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19.0 Coexistence 



There are no specific coexistence requirements for the initial release of the Linux 
tois initial re ease, nodes within the cluster will not be members of an alternate c 
AIX cluster While SP nodes may comprise part or all of the Linux cluster in this 
will not be functioning as Linux cluster nodes and PSSP nodes at the same time. 

Future versions of this design will address coexistence with existing AIX cluster 
Theowticaily, it is possible for one node to use multiple security 
such as the CtSec Infrastructure proposed in this document and FSSF's S3 

^^^^ " iS uaHWy thesc multi P le infrastniotures wiU tnter^op 
their differmg implementations and control structures. Inter-operation would also 
application to detect in which environment it was currently executing, and invoke 
structure for that environment. 
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This design continues the proposal offered in reference [1]: that an instance of a 
application execute in only one environment at any one time. In other words the si 
not be serving PSSP and the Linux or AIX cluster at the same time. If a case where 
reside in both a PSSP partition and a Cluster at the same time,the trusted service 
instance of its server for PSSP and.another instance for the Cluster. Each instance 
to use the appropriate infrastructure for that environment 



a < 



In cases where a trusted service in one environment (PSSP) would need to become 
trusted service in the other environment (Linux or ADC cluster), both environments * 
snared a common security mechanism. The common security mechanism would hav- 
environments; they could not share a common mechanism but use differing users 
seivers. If these requirements are not met, the trusted services would be forced to 
as an unauthenticated user; 
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